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AMENDMENTS TO THE DRAWINGS 



The attached sheet of drawings includes changes to Fig. 10 and includes both a Replacement 
Sheet and an Annotated Sheet Showing Changes. This sheet replaces the original sheet for 
Fig. 10. 

In Fig. 10, the Vector link 1 020 has been amended to clarify the relationship to the 
LINKTRANS 1010 showing the numerical listing 1-4, 7-9. 

The amendment is simply the addition of the sequential nvmiber before each element 
of the vector LINK 1020 and the corrected initialisation of vector elements according to 
LINKTRANS 1010. This amendment should help for the comprehension of the LINK vector 
and the LINKTRANS field. (Note that CA, CB, . . .are an hexadecimal representation of 
central memory addresses (pointers)). 



18 



Appl. No. 09/736,345 

Amdt. Dated Sept. 2, 2005 

Reply to Office Action of April 4, 2005 

REMARKS 

Claims 12-55 are pending. The Applicant has amended claims 12-15, 17, 20, 23-30, 
34, 36-44, 46-55. The offered amendments are to more clearly define the claimed invention, 
and place the case in condition for allowance. Alternatively, the offered amendments present 
the rejected claims in better form for consideration on appeal. Therefore, it is appropriate that 
the Examiner enter all the offered amendments into this application at this time. Rule 1 16(a); 
MPEP 714.12, 714.13. Reconsideration of this application and allowance of all pending 
claims is respectfully requested. 

Applicant thanks the Office for entering Amendment C filed after the final rejection on 
October 25, 2004 and Amendment D filed with the RCE on Jan. 21, 2005. 

Claims Rejections - 35 USC S102(b) 

The Office rejected claims 12, 13, 15-17, 20-43 and 48-55 under 35 U.S.C. 102(b) as 
being anticipated by Peachtree ("Peachtree Using General Ledger", copyright 1989 by 
Peachtree Software). A rejection based on anticipation requires that a single reference teach 
every element of the claim (MPEP § 213 1). "The identical invention must be shovm in as 
complete detail as is contained in the ... claim." Richardson v. Suzuki Motor Co., 9 USPQ2d 
1913, 1920 (Fed. Cir. 1989). Or stated in another way, a "claim is anticipated only if each and 
every element as set forth in the claim is found , . . . described in a single prior art reference." 
Verdegaal Bros. v. Union Oil Co. of California, 8 1 4 F.2d 628, 63 1 , 2 USPQ2d 1051,1053 
(Fed. Cir. 1987). 

The Office alleges that Peachtree teaches receiving 'accounting data' from an 
accounting system, wherein the 'accounting data' includes trial balance data having a number 
of accounts wherein each account has a corresponding account balance resulting firom one or 
more transactions and each transaction is associated with more than one account and 
combines at least one debit and at least one credit. 
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The Office thus believes that the present invention is an accounting system hke 
Peachtree, and thus importing of Peachtree data within Peachtree anticipates the presently 
claimed elements. Essentially, the Office then recites the elements of the claimed invention 
and tries to equate the claimed elements to features of Peachtree. As detailed herein, this 
comparison and equation fails. 

Peachtree is a bookkeeping software product allowing the creation and maintenance of 
a chart of accounts, the entering of transactions, and the printing of reports - one step after the 
other. The 'Balance Sheet' report and the 'Income Statement' report printed by Peachtree and 
identified as "financial statements" are only the result of the controlled sequential printing of 
this master list of accounts with account balances (the trial balance) along with the addition of 
sequential fictional accounts. 

As noted in Peachtree B1-B3, the structure of Peachtree is based upon the setup of the 
Chart of Accounts which includes account number, description, type, category. Group End 
value, and Balance column (see Peachtree 4-8). As noted by the Office on page 1 1 and 12 of 
the Office action, the Chart of Accounts is the master list of all Accounts by which Peachtree 
operates, as well as other accounting systems. 

Peachtree thus requires a pre-defined chart of accounts in order to fimction. Any data 
that is imported within Peachtree requires the structure according to the established Chart of 
Accounts in order to be processed. Typically, the user builds the Chart of Account and creates 
the structure (see Peachtree Chapter 3, Chapter 4 and the Setup Forms A1-A5). It is NOT 
possible for Peachtree to receive an electronic file of accounting data having only an account 
and amount as Peachtree would not be able to process this information. The present invention 
does not require a pre-defined chart of accounts. 
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As detailed in the present invention, the electronic file is used to compute the financial 
statements. An account balance is computed for each account, wherein each account has one 
or more amounts with a corresponding direction, such as a credit or debit. There are no 
"amounts" in the Peachtree Chart of Accounts - only the account features (see Peachtree 4-8). 
Even if Peachtree were to access an electronic file having trial balance data, it would not be 
able to process such data due to the Peachtree constraints (see Peachtree 3-21). 

As noted herein, the present invention receives an electronic file of accounting data 
having a plurality of accounts, wherein each account has a corresponding amount. Such an 
electronic file of accounting data can originate from a number of resources, including, but not 
limited to: from a Print command of software program; from an export or 'save as' function of 
a software program; from a scanning process that may include optical character recognition 
(OCR); and fi-om manually entered data saved into an electronic format. As fiirther noted in 
Claim 20, the accounting data can be obtained from reading trial balance data (accounts and 
respective balance) stored on a computer readable medium and/or reading transactions such as 
Peachtree table 2-18 stored on a computer readable medium, wherein the term 'computer 
readable mediimi' is given the broad definition as known to those in the industry. With either 
reading trial balance data or reading transactions, the present invention can build financial 
statements and display details. And, the accounting data being obtained from a universal 
process, such as a Print command of a trial balance and/or transactions, is unique to the 
present invention. 

Regardless of where or how the electronic file was generated - it contains 'accounting 
data' having a plurality of accounts, wherein each account has a corresponding amount and 
direction as noted herein. As will become readily apparent in the discussion herein, the rigid 
framework employed by Peachtree is unable to process such an electronic file of accounting 
data. For example, the Office uses the Peachtree table on 2-18 (re-created herein below) with 
respect to joumal entries to show an account with an amount and direction (credit or debit). 
However, while the present invention can receive this data in an electronic format and process 
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the data - Peachtree cannot because Peachtree requires the prior setup of the Chart of accounts 
and the ensuing constraints (see Peachtree 2- 18, 2-19). 

The Office further alleges that Peachtree encompasses 'receiving data' which includes 
manual entry as well as stating that this "method imports the information from other 
modules." The claims have been amended to clarify that the 'accounting data' is received in 
an electronic format or file, and thus traverses the rejection based on manual entry. 

With respect to the Peachtree importation limitations, the Transfer of Summary 
Journal is described beginning on pages 7-16 of the Peachtree cited reference. The Peachtree 
Transfer is simply a mechanism to post the journal entries to the general ledger accounts. 
"This program lets you take summary journals produced by other PCIII modules and transfer 
their figures into the General Ledger. You can transfer summary journals from Payroll, 
Accounts payable, Accoxmts Receivable, and Fixed Assets." (Peachtree page 7-16) The PCIII 
modules are briefly mentioned in the Preface (Peachtree i) and there are actually several PCIII 
modules that send information to the General Ledger as noted therein. These modules are 
essentially Peachtree 'special joumals' used to register transactions. Peachtree requires the 
accounting data to be handled in a rigid framework and the data fields and structures are 
intricately woven into the system which provides tight control and limits flexibility. 

The Office refers to Peachtree 2-18 table which illustrates the entry screen for journal 
entries and further references Peachtree 8-9 to 8-1 1 and states that "Peachtree teaches that this 
received (either manually or through the Transfer of Summary Joumal) accounting data is in 
fact trial balance data." 

For clarification, a trial balance, in general, is a report showing a chart of accounts 
with account balances (trial balance data) at a given time. The account balance is the result of 
transactions as is known. In an accounting system, the trial balance data is accounting data - 
but accounting data is technically not, in fact, trial balance data as set forth by the Office. 
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As noted, Peachtree is a bookkeeping software allowing the creation and maintenance 
of a chart of accounts, the entering of transactions, and the printing of reports - one step after 
the other. Following the setup procedures described in the Peachtree reference as further 
supported by the materials of Peachtree Appendix A and Appendix B, the trial balance data is 
the result of the bookkeeping process as used by accounting systems. Peachtree details the 
manual entry into its system and the manipulation of that data within the confines of the 
Peachtree software. In other words, the manually entered trial balance data has to be entered 
according to the Peachtree requirements such as sequence of accounts, numbering of accounts 
and account ranges in order to derive the trial balance presentation. 

For at least these reasons, a rejection based upon anticipation is traversed as the 
Peachtree does not teach each and every element of the claims. 

The Office also states that Peachtree describes grouping of the accounts in a maimer 
similar to the present invention. Peachtree describes the General Ledger and the types of 
typical General Ledger tasks in Peachtree 1-5, 1-6, along with the General Ledger transaction 
options. Peachtree Sec 2 also provides an example illustrating some maintenance activities 
with the General Ledger. 

Amended Claim 12 currently recites "grouping the accounts into one or more financial 
statement items, wherein each account is associated with only one financial statement item 
within any one financial statement and wherein said grouping is regardless of an account 
sequence." Peachtree operates according to the account sequence and does not permit 
'ranges' that are out of sequence. In addition, as detailed herein, Peachtree sequentially 
ft)llows the account sequence in the Chart of Accounts in Peachtree B1-B3 in the manner in 
which Peachtree prints out the "Balance Sheet" and "Income Statement" Reports. 
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The Office refers to the Peachtree table on 2-1 8 which is re-created below for 
reference: 



Ref# 


Description 


Acct# 


Amount 


Cr/Dr 


1408 


1 1/89 Service charges 


54000 


43.50 


Debit 


1409 


1 1/89 Service charges 


11000 


-43.50 


Credit 


1410 


Returned ck. #38456 


64000 


147.56 


Debit 


1411 


Returned ck. #38456 


11000 


-147.56 


Credit 



The Office states that the Expense Account and the Asset account are financial 
statement items and that "the roll up of Accounts 54000 and 64000 as 'Expense' represents 
grouping the two accounts into a financial statement." (Office Action page 4). This is 
incorrect, as 'Expenses' is a category of items as presented in Peachtree B-6 and do not have 
any respective balance. 

It is important to understand the terminology of the present invention as it aids in 
understanding the invention. A prior description in Amendment C dated Oct. 25, 2004 
included the following useful description which is recited herein for reference: 

In particular, the Applicant noted the widely accepted definitions for the following 
terms of art: 

An "account" is a grouping of transactions (debits and credits) that determine the net 
balance of the account; 

A "chart of accounts" is a list of accounts; 

A "trial balance" is a list of accounts with respective balances, where the balances 
result from the bookkeeping process of recording of transactions into accounts (a trial balance 
is not a financial statement); 

A "financial statement item" is a group of accounts; and 
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A "financial statement" is one of a balance sheet, income statement, statement of 
retained earnings, or a cash flow statement (a similar four types of financial statements exist 
for "not-for-profit" organizations as well). 

In Amendment D, the Applicant set forth a useful presentation of the hierarchical 
structure: "The hierarchal levels of data are as follows: 

Debits and Credits (which are amounts related to an economic event such as the sale of 
goods) provide one level of data, and come in combinations (e.g., Debit-Credit or Debit- 
Credit-Credit or Debit-Debit-Credit, etc) in accordance with the double entry accounting 
principle; 

A Transaction (which is an economic event that can be recorded using a Journal Entry) 
provides a next level of data, and includes a combination of Debits and Credits (note that, in 
accordance with the double entry accounting principle, the net balance of a Journal entry is 
zero); 

An Account provides a next level of data, and is a group of Debits and/or Credits from 
Transactions that determine the net balance of the account; 

A Financial Statement Item provides a next level of data, and is a group of Accounts 
that determine the net balance of the Financial Statement Item; and 

A Total of Financial Statement Items provides a next level of data, and is a group of 
Financial Statement Items that determine the net balance of the Total." 

As noted in the prior responses, these definitions were presented and it was explained 
that there is a hierarchical level for the data. With respect to Peachtree, title accounts 
(Peachtree 4-29 Step 7 and TYPl accounts in B1-B3) are shown in Peachtree B4-B5 - Assets, 
Current Assets, Fixed Assets, Other Assets, Liabilities & Equity, Current Liabilities, Long 
Term Liabilities, and Stockholders Equity are not financial statement items. A financial 
statement item is a group of accounts that determine the net balance of the Financial 
Statement Item, wherein an account is a grouping of transactions (debits and credits) that 
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determine the net balance of the account. The Income, Cost of Goods, Expenses, Other 
Income, and Other Expenses noted in B-6, B-7 are also not Financial Statement items as they 
have no respective balances . 

Peachtree provides accounts of the Chart of Accounts along with balances in its 
"Balance Sheet" and "Income Statement" Reports. As detailed herein, Peachtree is not able to 
perform the grouping function as described and claimed in the present application that 
performs grouping regardless of the account sequence. Peachtree operates sequentially with 
respect to the Chart of Accounts referenced in Peachtree B1-B3. Peachtree operates by 
sequentially stepping through the chart of accounts with printing control to display the titles 
and adding account balances of certain ranges of the account sequences. 

As observed by Office, the Chart of Accounts is the master list of all Accounts by 
which Peachtree operates, and the 'Balance Sheet' report and the 'Income Statement' report 
printed by Peachtree and identified as "financial statements" are only the result of the 
controlled sequential printing of this master list of accounts with account balances (the trial 
balance) along with the addition of sequential fictional accounts. 

As noted in Peachtree 8-13, General Ledger lists accounts in numerical order on this 
report and reflects Balance Sheet subtotals and totals as established in the Chart of Accounts. 

The Trial Balance report also shows balances for these accounts. 

Looking at the Chart of accounts on page B-1 to B-3, the accounts are in ascending 
order of their account numbers starting from account 100 to 999. As noted in Peachtree, 
there is a distinction between Balance Sheet account and Income Statement account 
(Peachtree 4-28, 4-30, 4-32, 4-33) and a segregation in two parts is made for the Chart of 
Accounts to allow the sequential printing of the Balance Sheet accounts in the 'Balance Sheet' 
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report and the sequential printing of the Income Statement accounts in the 'Income Statement' 
report. 

To simulate the presentation of financial statements, Peachtree adds temporary 
accounts: title accounts (type 1), Master/Department Control accounts (M/D), subtotals 
accounts (type 3-8) and totals accounts (type 9). The Office refers to these as temporary 
accounts. These fictional accounts are added permanently to the Chart of Accounts and are 
not able to be edited as "you can not make journal entries to them. "(Peachtree 4-29, 4-24, 4- 
31). As expressly stated by Peachtree, the two financial reports of Peachtree are simply the 
printing of accounts: 

If you want to see how General Ledger uses Titles accounts, look at the Balance Sheet 
printed in Appendix B, Standard Chart of Accounts and Financial Statements. 
Compare it to the standard Chart of Accounts in the same appendix. 
Find the type 1 (title) accounts on the Chart of Accounts and see where those 
titles appear on the Balance Sheet. Remember that the titles you see here are the 
same ones that General Ledger automatically supplies when you create a standard 
Chart of Accounts. (Peachtree 4-29) 

Again, Peachtree simply lists accounts in numerical sequential order on this report as 
established in the Chart of Accounts, and while printing, Peachtree performs certain printing 
controls to add certain ranges as designated by the Master accounts. Peachtree therefore 
teaches the use of accumulators for specific range of consecutive accounts and each Master 
Control account subtotals the accounts numbered higher than itself and lower or equal to the 
Group End number (Peachtree 4-24). 

For example, as shown in Peachtree B-1, Account number 105 is Cash and is a Master 
account that forms a sequential accumulative range from account 105 through 1 19, the group 
end. Thus, Account 1 10 'Cash - Operating' and Account 115 'Cash on Hand' are added to 
the Account 105 Cash amount. 
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Peachtree does not allow for the grouping of the accounts into one or more financial 
statement items, wherein each account is associated with only one financial statement item 
within any one financial statement and wherein said grouping is regardless of an account 
sequence. For at least these reasons, the rejection is traversed. 

The Office also alleges that Peachtree groups the financial statement items into one or 
more totals wherein each total is based on preceding financial statement item balances. As 
described herein, Peachtree operates sequentially in the formation of 'ranges' according to the 
Chart of Accounts in order to print the financial statement reports, namely the Balance Sheet 
and hicome Statement. 

The present invention processes financial statement items, balances and total balances 
as noted in claim 12, "computing a financial statement item balance for each financial 
statement item based on the associated accounts and their respective account balances; 
grouping the financial statement items into one or more totals, wherein each total is based on 
preceding financial statement item balances; and providing a financial statement that includes 
each financial statement item and its respective balance." 

In more particular detail, as noted in Peachtree B-1, the subtotal is Type 4 and 
accumulates all sequentially preceding Type 2 accounts. For example, Accoimt 140 - 'Total 
Current Assets' would accumulate all the accounts in the preceding sequential range from 105 
to 140. Such a process does not allow non-sequential accumulation which is provided by the 
present invention that allows for the grouping of the financial statement items in a manner 
irrespective of the sequence. In fact, the present invention allows grouping of any accounts 
regardless of the sequence or account identification such as account number/account title. 

As detailed in Peachtree 4-3 1 , when General Ledger encounters the Type 3 through 8 
accounts as it prints financial statements, it prints the accumulated total of preceding type 2 
accounts, and the contents of the accumulator identified by the type number is printed and 
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then reset to zero. In Peachtree, the General ledger clears the subtotals maintained by account 
types 3 through 8 each time one of these accounts is used. When General Ledger encounters 
the Type 9 accounts as it prints financial statements, it prints the accumulated total of 
preceding type 2 accoxmts, and the contents of the accumulator identified by the type number 
is printed and not reset to zero, as the Total accotmt values are never cleared to zero since 
Total accounts act like rurming totals. (See Peachtree 4-33 item 2.) No grouping process 
exists in Peachtree - simply a printing process. 

As described in the present application, there is a "distinction between two types of 
balances (financial statement items and totals) appearing on a financial statement; enabling the 
user to group the accounts into financial statement items simply and rapidly, by pointing, 
through the data structures and the display module; enabling the user to group the financial 
statement items into totals simply and rapidly, by pointing, through the data structures and the 
display module, and considering that any total in a financial statement comes from balances of 
preceding lines." (Claim 1 Published Patent Application US 2001/0044762 Al) 

The sequential processing of Peachtree does not provide for the claimed elements and 
for at least these reasons, the rejection is traversed. 

With respect to the levels of detail noted in amended claims 13, 15, 17, the Office 
alleges that Peachtree provides such a capability. However, Peachtree does not allow for the 
breakdown levels of detail for the grouping in a non-sequential manner. Furthermore, the 
amended claims include the levels of detail from a display of the financial statement . The 
levels of detail according to the present invention are obtained directly from the display of the 
financial statement. Peachtree has no such capability. 

As expressed in the background section of the present application, accounting systems 
usually output a project of a financial statement which is typically used only by the directors. 
The user must respect a rigid firamework which is pre-established, fixed and limited to one 
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type of presentation, often the statement of results or the balance sheet, without the 
complementary notes (which are an integral part of financial statements) and the additional 
information. Also, the consultation of these financial statements on the screen is limited to the 
report itself and the user cannot go back to find the source of the information. The present 
invention allows the user to navigate fi:om the financial statement information displayed to the 
user and provides the ability to quickly locate additional information in the first, second and 
third levels of detail. For at least these reasons, this rejection of Claims 13-17 is traversed. 

The Office states that Peachtree is capable of receiving accounting data by reading trial 
balance data stored on a computer readable medium and/or reading transaction stored on a 
computer readable medium. However, Peachtree, like most complex software, has specific 
data arrangements and does not permit easy importation or receiving of data fields such as 
accounting data. As articulated herein, the importation of data within Peachtree modules is 
limited. Peachtree does not allow importing of data in any format with the exception of 
backup Peachtree data or the internal transfer of joumal entries. Thus, Peachtree describes a 
transfer of certain data between internal Peachtree modules but not an electronic file of 
accounting data having a plurality of accounts, wherein each account has a corresponding 
amount. 

By way of fiirther illustration of one embodiment, the present invention can receive an 
electronic file, such as an ASCII file that can be easily generated by a Print command, and 
process the data. Furthermore, data from Peachtree can even be saved as an ASCII file and 
used by the present invention. BUT, that same ASCII file generated by Peachtree CANNOT 
even be input back to Peachtree. Therefore, Peachtree does NOT "import" accounting data 
from other modules or provide for later retrieval of such accounting data by reading trial 
balance data stored on a computer readable medium and/or reading transaction stored on a 
computer readable medium. For at least these reasons. Claim 20 is traversed. 
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A further aspect of the present invention includes the integration of the method 
claimed herein, wherein the method is integrated into accounting software (Claim 21) and/or a 
word processor, spreadsheet or editing system (Claim 22). It should be noted that at the time 
of the invention, editing software was considered to be those products such as Adobe 
Pagemaker or QuarkExpress in the field of what is now generally termed desktop publishing. 

The Office states that Peachtree is accounting software and alleges all the claimed 
features are taught by Peachtree and thus integrated into accounting software. As argued 
herein - Peachtree does not teach the methods of the present invention and although the 
ftmctionality of the present invention may be incorporated into Peachtree - such fiinctionality 
does not presently exist. Likewise, the Office states that Peachtree represents 'editing 
software' and allows one to 'tailor' the general ledger. Claim 22 reflects that the present 
invention can be integrated into any word processor software, spreadsheet software, and/or 
editing software. Peachtree CANNOT be integrated into any word processor, spreadsheet 
software and/or editing software as it exists unto itself 

The Office alleges that Peachtree displays financial statement with detail associated 
with any financial statement item balance. The amended claims more clearly define the 
present invention components such as pointers (central memory addresses), doubly linked data 
structures, and doubly linked list/sub-list of pointers. This makes it easier to distinguish the 
present invention as it allows consulting a financial statement on the screen, and to rapidly go 
back to the source of the financial statement items balances presented in a financial statement 
built using the method taught by the Financial Statement Module, as claimed at claim 23. 

The direct access provided by the sub-lists of electronic addresses, that is the sub-lists 
of trial balance data structure element pointers 1014 linked to financial statement data 
structure elements and the sub-lists of displayline data structure element pointers 1030 linked 
to trial balance data structure elements: While consulting the report of a financial statement of 
which an example is shown at FIG. 18, the user can select a line and obtain detailed 



31 



Appl. No, 09/736,345 

Amdt. Dated Sept. 2, 2005 

Reply to Office Action of April 4, 2005 

information 208. The first level of detail is the detail of an item 1901 which is obtained by 
inserting, in the display structure 1401 and in the list of pointers 1409 an element 1417 for 
each element in the sub-list item 1014 of the item selected. The present invention saves the 
pointer of the chart structure 101 1 of each element in the display structure 1418 and displays 
the modified report 1900. The user can manipulate the display and print the document or 
select a balance to obtain the detail of this balance, (see present Specification lines 7-14 page 
30) 

The detail of a balance is obtained by going through the sub-list of display structure 
pointers 1030 from the pointer to the display line of the first transaction 1027 until the pointer 
to the display line of the last transaction 1028 linked to the account of the chart structure 
corresponding to the pointer of the chart structure stored in the display structure 1418 of the 
line selected. For each element of the sub-list, a similar element is created and inserted in a 
distinct list of display structure pointers as in 1409 to assemble a report as shown in FIG. 20 
containing the list of transactions comprised in the balance of the account. The display 
structure pointer for each element of the distinct list is initialized to the one contained by the 
element of the sub-list. ( see present Specification line 29 page 36 - line 7 page 37) 

To finish the list of transactions, a last line composed of a page jump 1406 is added to 
the list. The module stores the pointer to the first element 1407 and the pointer to the last 
element 1408 of this list 1402. The list then goes through the skeleton of reports of FIG. 16 to 
build a report to display and print by adding headers and page jumps inside of the list of the 
display structure. The user can manipulate the display, print the document of FIG. 20, come 
back to the previous detail level, or select a transaction to obtain the details, that is, the detail 
document which lists the transactions which compose this document as shown in FIG. 21.( see 
present Specification, lines 6-13 on page 40) 

FIG. 21 shows the presentation of the detail of a document. In this case, the transaction 
structure has been optimized. In the other case, the presentation would be of the type of FIG. 
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24, with the Debit and Credit columns, (see lines 15-17 on page 40 of the present 
Specification) 

The module looks in the transaction structure 2201, for the first transaction and the last 
transaction which build this document, that is, the transactions having the same date and the 
same document number, starting firom the transaction pointer saved in the display line 2218. 
The module then builds a distinct list of display pointers from the display line pointers saved 
in the transaction structure 221 l(line 19-23 on page 40) 

Claims 13, 15, 17, and 23 have been amended in accordance to more clearly define the 
invention and the rejections are traversed for at least the reasons set forth herein. 

One of the further amendments is related to the identification of the 'memory' 
indicated in the claims. According to the Specification of the application, the claims are 
referring to the central memory of a computer. Consequently, the claims are amended to 
change 'memory' for 'central memory' for clarity. Unlike Peachtree and other systems that 
write/read to/from a hard drive or extemal memory, the present invention performs processing 
of the accounting data in the central memory, for example RAM. 

The Office makes additional allegations and rejections with respect to 'doubly linked 
structures' and 'dynamically allocating memory spaces'. According to the Specification of the 
present application, dynamically allocating memory spaces refers to the process of allocating a 
memory space for each data structure element, on a one by one basis, as needed, in the central 
memory of the computer. It also means reallocating the central memory space of an element 
when this element is deleted (removed) from the data. Claim 24 is consequently amended to 
clarify the understanding of the individual dynamic allocation in the central memory of the 
computer. Most accounting system software uses extemal memory, a mechanical process, and 
accesses a hard drive to operate. The present invention uses the electronic central memory, no 
mechanical process, to allow for fast accounting data processing. 
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Also, as observed starting from page 1 1 of the Office Action, the definition of 'doubly 
Unked data structure' referred to in the claims defines how elements of a data structure are 
linked together to form a data structure, and not how elements of different data structures can 
be linked. 'Doubly linked' means that each data structure element is linked to the next 
element (first link) and to the previous element (second link) by storing the address of these 
next and previous elements. Claim 24 has been amended to clarify the present invention to 
refer to 'doubly linked data structure'. 

A further clarification is provided with respect to 'pointers', to eliminate any 
ambiguity such as (account numbers) being interpreted as pointers (see page 12 of the Office 
Action). The pointers in the present invention are central memory addresses returned by the 
memory allocation function. Since the present invention dynamically allocates a central 
memory space on a one by one basis for each individual element of a data structure and since 
the return value of a memory allocation function is a pointer (the central memory address of 
an available central memory space allocated) the data structures are "doubly linked" by using 
the insertion algorithm of Table 1 in the specification to store the 'NEXT' and 'PREVIOUS' 
data structure element pointers in the current data structure element, that is the central 
memory address of the next element in the data structure and the central memory address of 
the previous element in the data structure, which pointers (central memory addresses) are 
function of available central memory spaces at allocation time, so pointers are in random 
order rather than in a sequential order. 

These amendments to claim 24, referring to 'central memory', providing the individual 
dynamic allocation of central memory spaces, identifying 'pointer' as a central memory 
address and, defining 'doubly linked data structure' by how the data structure elements are 
linked together with pointer 'next' and 'previous' to form a data structure, should eliminate 
any possible comparison as a "check number'' used as a Reft^ in Peachtree (7-5) being a 
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memory address of a particular element in the trial balance (chart of accounts) data structure 
(page 14 of the Office Action). 



Using these pointers, you can go through the data structure sequentially starting from 
the central memory address of the first element of the data structure and move to the central 
memory address of the next elements until the last element, or, being 'doubly linked', you can 
go through this data structure sequentially the other way, starting from the central memory 
address of the last element of the data structure and move to the central memory address of the 
previous elements until the first element of the data structure. Once again. Applicant v^ishes 
to reiterate that the present invention processes of the accounting data are performed in the 
central memory and not an external hard drive with respect to this feature of claim 24. 

Since new element can be inserted anywhere in the data structure, no matter what 
central memory address is available, the process of individual memory allocation space 
combined with the doubly linked data structure offers great flexibility for organizing and 
manipulating the accounting data, and fast speed process considering the use of central 
memory addresses (pointers) providing electronic access, with no mechanical process, to the 
accounting data. 



For illustrative purposes. Applicant refers to Figure 10 element 1030 to present a 
detailed explanation of an addition of a structure element using the algorithm of Table 1, by 
initializing a new data structure element (allocated central memory address: GD) pointers 
NEXT (GC) and PREVIOUS (GB) along with the NEXT pointer of the previous element and 
the PREVIOUS pointer of the next element. 
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Next Previous pointer 
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An example of this flexibility is for the addition of a new account in the chart of 
account. A new account can be inserted anywhere in the chart of accounts without 'disturbing' 
the other accounts, and working with pointers and doubly linked list of pointers, the account 
number is not used or required as an index, contrary to most accounting software such as 
Peachtree (see examples of constraints imposed by accounting software for account numbers 
on page 3-21 to 3-24 in Peachtree). 



Knowing that financial statement items are groups of accoimts, and knowing that 
elements of the trial balance data structure needed to be 'doubly linked' for more than one 
purpose, instead of storing the 'NEXT' and 'PREVIOUS' pointers in each trial balance data 
structure element, as specified in claim 25 the present invention uses distinct doubly linked 
lists of trial balance data structure element pointers illustrated in Figure 5 of the present 
application such as 501 for the Chart of Accounts, and such as 505 for the grouping of 
accounts into financial statement items to 'doubly link' the elements of the trial balance data 
structure as needed. 

Here the flexibility is even more evident since modifying the grouping for financial 
statement item will not affect the Chart of Accounts and modifying the Chart of Accounts (the 
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sequence of the accounts, account numbers, addition of new accounts, etc.) will not affect the 
grouping for financial statement item. 

Claims 25, 40, 48, 54-55 are amended herein to specify the type of sub-lists, being 
sub-lists of pointers, and claims 29 and 30 are amended to clarify the type of pointers and to 
indicate that a sub-list is simply a list in a list. For at least the reasons presented herein, the 
rejections are traversed. 

A notable distinction refers to the use of central memory recited in claim 25, wherein 
the present invention does not employ extemal drives as is further described herein. Peachtree 
stores data onto hard drives and access is to/from the hard drive. For the other part of the 
accounting data, the transactions, the present invention also use the central memory allocation 
functions that return pointers (central memory addresses) to dynamically allocate individual 
central memory spaces for each transactions at available central memory spaces. 

As for the elements of the trial balance data structure that are 'doubly linked' for more 
than one purpose, knowing that doubly linking for more than one purpose could be useful for 
transactions, the present invention uses doubly linked lists of pointers, and displayline data 
structure element pointers, to 'doubly link' these transactions elements as needed, allowing 
the building of different lists of pointers for various type of transactions reports. 

Also, knowing that sub-list is a list linked to an element of another list, such as shown 
in Figure 5, element 505 is linked to an element of the financial statement data structure, the 
present invention uses sub-lists 1030 of displayline data structure element pointers to link lists 
of transactions associated with a particular allocation account, which simply requires that the 
central memory address of the first element of this list 1030 be stored in the associated trial 
balance data structure element 1027, as for the last element 1028 the list 1030 being doubly 
linked, (see lines 6-11 on page 34 of present Specification). 
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Claims 36-38 are amended to clarify the identification of the pointers from 'display 
line structure element' to 'displayline data structure element'. Claim 38 is also amended to 
indicate that a sub-list is simply a list in a list. 

The unique accounting data organisation in the central memory of a computer could be 
void each time the computer is tumed off, so a save on an external memory, such as a disk for 
example, must be performed before the computer is tumed off But the pointers (central 
memory addresses) returned by the memory allocation functions used for the dynamic 
allocation of individual central memory spaces at available memory addresses can not be save 
on extemal memory. To rebuild the distinct lists of trial balance data structure element 
pointers, the present invention use a vector (a sequential data structure) called the LINK 
vector that stores the central memory addresses (pointers) of the individual allocated memory 
spaces for the trial balance data structure elements. 

When the elements of the trial balance data structure are reloaded in the central 
memory by the invention, using the memory allocation functions to allocate central memory, 
spaces on a one by one basis, for each trial balance data structure element at the then available 
central memory spaces, the new pointers (central memory addresses) returned by the memory 
allocation functions will be stored in the LINK vector and the doubly linked lists of pointers 
grouping the accounts into financial statement items will be rebuilt using theses new pointers 
stored in the vector according to the vector element sequential number stored in the trial 
balance data structure in a field called LINKTRANS which sequential number was saved in 
the trial balance file (1201 in Figure 12) and in the financial statement file (1301, 1302, 1303 
in Figure 13) (see lines 14-19 on page 19 of the present Specification). 

Claims 26, 41 and 49 are amended to precisely define the components of the LINK 
vector and the LINKTRANS field, which field in the trial balance data structure stores the 
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sequence number of the creation of the account. For at least the reasons presented herein, the 
rejections presented herein are traversed. 

Amended Figure 10 of the present appUcation includes the addition of the sequential 
number before each element of the vector LINK 1 020 and the corrected initialisation of vector 
elements according to LINKTRANS 1010. This amendment should help for the 
comprehension of the LINK vector and the LINKTRANS field. (Note that CA, CB, . . .are an 
hexadecimal representation of central memory addresses (pointers)). 

This concept is used to rebuild the sub-lists of pointers 1030, doubly linking 
transactions associated with a particular allocation account. The present invention uses the 
LINK vector and the LINK vector element sequential number stored in the LINKCHART 
field of the transaction data structure to access the sub-list addresses 1027-1028 of the 
associated allocation account thru its new pointer (central memory address) stored in the 
LINK vector by the reload process. 

Claims 34 and 51 are amended herein to more clearly define the components of the 
LINK vector and the LINKCHART field and for at least these reasons the rejection is 
traversed. 

A similar concept is used when a debited account and a corresponding credited 
account are stored in a single element The present invention uses the LINKB ANK field to 
access the sub-list of the other associated account in the same way it uses the LINKCHART 
field, so the single element will be part of two doubly linked sub-lists (Fig. 10 - element 
1030), and are linked to two accounts. 

The Office also rejects claims 27, 28, 39, 42, 48, 53 and 55 by alleging that Peachtree 
teaches storing financial statement elements into a financial statement data structure as noted 
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in Peachtree B1-B3. However, Peachtree only describes the chart of accounts - there is no 
distinct financial statement data structures articulated in Peachtree. The Peachtree table Bl has 
a "TYP" that refers to the type of accounts for the Chart of Accounts - this is not the LINE 
type associated with the financial statement data structure of the present invention. As 
explained in the present application there are two types of balances provided in a financial 
statement, namely a financial statement item balance and a total balance. For at least these 
reasons, the rejection is traversed. These claims, including amended claim 28, indicate that 
there are two types of balances provided in the financial statement. 

The Applicant's claims define a method or computer program product for use in 
building financial statements that allows the reading of any trial balance data and/or 
transactions, and the displaying of balance detail. Peachtree is a bookkeeping software product 
allowing the creation and maintenance of a chart of accounts, the entering of transactions, and 
the printing of reports. 

The Office alleges that Peachtree maintains a direction field in the trial balance 
structure as claimed in claim 3 1 . Peachtree does not disclose or describe maintaining a 
direction field in the trial balance data structure for each account. The Cr/Dr column of the 
Table on page 2-18 represents a direction field for each transaction amount, not a direction 
field for each account. This Table illustrates the entry screen for joumal entries and this does 
not allow enabling a user to identify a transaction amount's effect on the corresponding 
account balance because the user does not see the accounting direction of the corresponding 
account, therefore, the user can not see if the transaction's amount increase or decrease the 
account balance. 

As is well known in accounting, the notions of addition and subtraction and of positive 
or negative totals are slightly changed. There are debit balances and credit balances which are 
increased or decreased by debiting or crediting amounts. Therefore, a debiting balance is 
increased by debiting an amount and is decreased by crediting an amount. A credit balance is 
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increased by crediting an amount and decreased by debiting an amount, (see lines 18-23 on 
page 20 of the present Specification) 

Table of page 2-18 shows that when a negative number is enter, Peachtree put 'Cr' on 
the entry screen, and put 'Dr' if the number is positive. The Cr/Dr field does not represent 
Applicants Journal field (claim 35). Peachtree Tables 2-18, 8-8, 8-1 1 and 8-14 ('Allowance 
for Bad Debts' and 'Accumulated Depreciation' accoimts) show clearly the direct correlation 
made by Peachtree, as for accounting software, between the mathematic sign of the number 
and the accounting direction of the transaction amount: 

negative number = credit amount 

positive number = debit amount 

so, the direction of each transaction is simply indicated by the mathematic sign of the number. 

This is clearly put in evidence by Table on Peachtree page 8-1 1 where for the accoimt 430 
Allowance for Bad Debts' you see a beginning credit balance of ' 51,447.50 - ' being 
increased with a transaction credit amount of ' 3,500.00 - ' for an ending credit balance of ' 
54,947.50 - ', which is the account balance printed with the account 'Allowance for Bad 
Debts' in the 'Balance Sheet' report of page 8-14. 

The same conclusion is observed with the account '160 Accumulated Depreciation' 
for which you see on page 8-1 1 a begirming credit balance of ' 454,940.66 - ' being increased 
with a transaction credit amount of ' 15,679.09 - ' for an ending credit balance of ' 470,619.75 
- ', which is the account balance printed with the account 'Accumulated Depreciation' in the 
'Balance Sheet' report of page 8-14. 

There is no Journal field such as for the present invention, where each transaction 
amount is stored as a positive number in the transaction structure, to indicate the accounting 
direction of each transaction amount (see present Specification, line 30 page 33 to line 4 page 
34) and when optimized (one transaction line for the debit and the credit), the accounting 
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direction of the same transaction amount will vary, according to the Journal field (see lines 
23-27 page 36 of the present Specification) and, there is no direction field maintained for each 
account. For at least these reasons the rejection of claims is traversed. 

As detailed herein, the amended claims and the arguments herein overcome the 
rejections and allowance of all claims is respectfiiUy requested. 

Claim Rejections - 35 USC § 103 

The Office has quoted the statute firom 35 USC 103(a), which is referenced herein. The 
Office has rejected claim 14 and 18 - 19 as being unpatentable over Peachtree in view of 
Official Notice and claims 44 -47 as being unpatentable over Peachtree in view of Sampson 
(U.S. Pat. No. 5,390,1 13). Applicant has carefully considered the Office rejections and 
respectfiilly submits that the amended claims, as supported by the arguments herein, are 
distinguishable fi-om the cited reference. 

According to the MPEP §2143.01, "[ojbviousness can only be established by combining 
or modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found in either the references themselves or in the 
knowledge generally available to one of ordinary skill in the art." 

A usefiil presentation for the proper standard for determining obviousness under 35 USC 
§ 103(a) can be illustrated as follows: 

1 . Determining the scope and contents of the prior art; 

2. Ascertaining the differences between the prior art and the claims at issue; 

3. Resolving the level of ordinary skill in the pertinent art; and 

4. Considering objective evidence present in the application indicating obviousness 
or unobviousness. 

Claims 14 and 18-19 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Peachtree and in view of an Official Notice. The Applicant has considered 
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this rejection and traverses this rejection as detailed herein and allowance of the claims is 
respectfully requested. 

The Office alleges that Peachtree provides a direction for the account. Whether it is 
with a minus sign or with parenthesis, Peachtree simply teaches identifying credit transaction 
amoimt and credit account balances with such sign, not if direction is opposite to assigned 
accounting direction. The Tables on pages 2-18, 8-8, 8-1 1 and 8-14 clearly show that 
Peachtree makes a direct correlation between the mathematic sign of the number and the 
accounting direction of the transaction amount: 

negative number = credit amount 

positive number = debit amount 

so, the direction of each transaction is simply indicated by the mathematic sign of the number, 
and consequently the account balance with a minus sign to its right indicates a credit balance. 

As taught by the present invention, the direction field maintained in the chart structure of 
the Financial Statement Module has several purposes. One is to enable a user to identify a 
transaction amount's effect on the corresponding account balance while consulting the 
account balance detail (2"^ level of detail - Figure 20 -claim 15). In Figure 20 of the present 
application, in addition to indicating the direction D for debit or C for credit for the 
transaction 2003 in the presentation, the financial statement module displays a 2004 or a 

according to the direction of the account 1029 to facilitate the comprehension of the effect 
of the transaction on the balance of the account. The direction of the account shown 2005 is 
attributed during the building of the chart structure 304 from the accounting data and can be 
modified by the user in the data entry screen of the trial balance 305. As explained herein, 
with the accounting equation of Figure 15, a transaction debiting an account for which the 
direction is debit displays a As well, a transaction crediting an account for which the 
direction is credit displays a A is displayed when the direction of the transaction is 
different from the direction of the account, for example, in the case of a transaction crediting 
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an account for which the direction is debit or a transaction debiting an account for which the 
direction is credit.(see line 27 page 37 to line 9 page 38 of the present Specification) 

Another purpose is to allow the elimination of non appropriate parenthesis in financial 
statements. When a financial statement is built, positive numbers and negative numbers are 
not shown. What is shown is balances. According to the accounting equation, the balances on 
the left of the equation are debit balances and the balances on the right of the equation are 
credit balances. For each account, a direction is attributed 1029. The tag D is for debit and the 
tag C is for credit. For each item, the module uses the direction of the first account of the item 
to determine the direction of the item. Each total resulting of the addition of the balances of 
each of the accounts pointed to in the sub-list of the item 1014, is multiplied by 1 or by -1 
according to the direction (D or C) of the first account of the item. A negative result for this 
multiplication is shown in parentheses for display purposes of the balance on the financial 
statement (see lines 19-28 on page 21 of the present Specification). A balance is shown in 
parentheses only if it is of opposite direction to the direction of the item and not if it is a credit 
balance or not if it is of opposite direction to the direction of a section of the financial 
statement or of the whole financial statement in which it is shown. 

Therefore, a debit balance is shown in parentheses if the direction of the item is a credit, 
and a credit balance is only shown in parentheses when the direction of its item is a debit. The 
same principle applies for the presentation of the balances of the totals. The module uses the 
direction of the first accoxmt of the first item of the total to determine the direction of the total. 
The total of a balance for a line of type total comes from the addition of the balances of each 
of the accounts pointed to by the sub-list item of each of the items pointed to by the sub-list 
total of the total. Each total is multiplied by 1 or by -1 according to the direction (D or C) of 
the first account of the first item. A negative result for this multiplication is shown in 
parentheses for display purposes (see lines 1-14 on page 22 of the present Specification). 
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If Peachtree taught maintaining an accounting direction for each account, the minus sign 
to the right of the balance of the account 'Accumulated Depreciation' in the 'Balance Sheet' 
report of page 8-14 would have been eliminated since it is well known in the art that the 
account 'Accumulated Depreciation' is a creditor account. 

Claims 44-47 were rejected under 35 U.S.C 103(a) as being unpatentable over 
Peachtree in view of Sampson. For at least the reasons presented herein, the rejection is 
traversed. 

The Office acknowledges that Peachtree does not teach optimizing allocation of memory 
spaces. However, the Office alleges that Sampson provides such optimization. Looking at 
Sampson Figure 8 and 10, it is evident that the transaction data structure of Sampson is not 
'reducing the number of memory spaces that must be allocated for storing transactions'. Since 
Sampson requires more memory spaces to create 'intermediate record' noted in Sampson 
Figure 8 for totals and to store the journal entries. The 'intermediate' records are added 
'between' the journal entries and the accounts balances, as shovra by Sampson Figure 8, with 
'POINTER TO LIST OF TRANSACTION ID RECORDS' pointing to Sampson Figure 7 
'entry IDs', which 'entry IDs' point to journal entries of Sampson Figure 10. 

So not only does Sampson need more space for the new intermediate records, but also 
requires space to store the original journal entries. As noted in Sampson, the original "journal 
entry, complete with debit and credit, is the canonical record" and is retained by Sampson. 
(Sampson Col 8, lines 41-43; Col 12, lines 6-7) 

As described in Sampson, "[i]n FIG. 7, there is shown a schematic representation of a 
chain of entry IDs, EN(1) through EN(n), identifying the original joumal entries, JOURNAL 
ENTRY (1) through JOURNAL ENTRY (n), which share a unique design. Each of the records 
shown in FIG. 3 contains a pointer which begins a chain of joumal entry identifiers. The "N" 
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field in FIG. 3 contains the number of journal records identified in the chain for each 
summary. (Sampson: column 13; line 66 - column 14; lines 5) 

Sampson further states that "if the memory capacity is available, the journal entries can 
be stored, in a memory 35 connected to the computer 32, in the order defined by the chain of 
each design record or simply by entry number." (Sampson: column 1 1 ; lines 44-47) And 
even further, "[t]he memories 33, 34 and 35 can be separate memories or a large disk storage 
device interfaced with the computer 32." (Sampson: column 12; lines 61-63; See Sampson 
Figure 4) 

Thus, it is obvious for a person of ordinary skill in the art, that Sampson does not 
teaches reducing the number of memory spaces that must be allocated for storing transactions, 
neither does it teaches optimising allocation of memory spaces for storing transactions 
included in the accounting data by storing debited account and a corresponding credited 
account in a single element of the transaction data structure, as claimed by the present 
invention. 

Furthermore, the present invention claims the usage of "central memory" and not the 
disc drive or external memory described by Sampson. For at least these reasons the rejections 
are traversed. 

In addition, claim 46 has been amended to be more specific about the theoretical 
balance being a theoretical account balance which should the traverse the rejection. 

Claim 47 is amended to clarify the components of the LINK vector and the 
LINKBANK field, and for the reasons herein, the rejection is traversed. 

As described in the application and in the amended claims, the present invention 
imports accounting data stored in an electronic file. The accounting data represents an 
electronic data format from any accounting system. This accounting data comprises at least an 
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account identification (number and/or title or description), and an amount which is 
represented as a debit or credit. 

As illustrated in the Applicant's Figure 3, the accounting data 300 comes from any 
accounting software package, for example, any trial balance that is displayed in an electronic 
format and stored into an electronic format such as by using the 'print to file' option from a 
print menu that stores the data into an ASCII file. The electronic format data is stored on a 
computer readable medium in 302. This trial balance data stored in 302 can be read by process 
303 using well-known conventional data reading techniques (see line 26 page 8 to line 3 page 
9 of the present Specification). For example, the present invention can simply read the ASCII 
code of a trial balance report printed on disk (ASCII file) instead of paper and allocate a 
central memory space for each data structure element for storing this accounting data 
(accounts identification, balance) and link data structure elements with doubly linked lists of 
pointers (central memory addresses), which allow the organization and manipulation of any 
trial balance. 

Similarly, accounting transactions listed in transactions reports and stored on a 
computer readable medium 306 can be similarly read using process 307 (lines 3-5 on page 9 
of Specification). The invention loads this accounting data in the doubly linked transaction 
data structure and the associated displayline data structure element of Figure 22 and link 
transactions to allocation accounts, according to the account identification available on all 
transactions reports, with doubly linked sub-lists of displayline data structure element pointers 
1030. The invention will further compute the amounts according to the accounting equation 
not according to mathematic sign of numbers. 

Claims 12-15, 17, 20, 23-30, 34, 36-44, 46-55 are currently amended for clarification 
and to more succinctly claim the subject matter of the present invention. 
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At this point it should be evident that any accounting software, such as Peachtree for 
example, can integrate the current invention universal methodology for building financial 
statements. In some embodiment the accounting system can simply import bookkeeping data 
by going through the printing/reading of ASCII files, importing the data or otherwise 
obtaining an electronic file of the data. Also, as expressed in the Background of the invention, 
word processors offers all the flexibility required to produce final and complete financial 
statements, but word processors offer no integration with the accounting data of accounting 
systems. 

With this universal method for building financial statements providing the capacity to 
read, organize and manipulate the accounting data of any accounting software, word processor 
software such as Microsoft Word, Wordperferct, or spreadsheet software such as Microsoft 
Excel, Lotus 123, or editing software such as PageMaker, QuarkXpress, will be able to 
integrate accounting data of any accounting systems . Some accounting software systems 
offer the ability to save data into readable files by other software systems. The financial 
statement module of the present invention provides the capability to read, organize and 
manipulate accounting data printed to a file instead of paper by any accounting software 
therefore allowing other software (such as spreadsheets) to read the accounting data. It is no 
more the accounting software that allows the other software to read its accounting data. 
Rather, the other software has the capability to read the accounting data of any accounting 
software. 

The Applicant believes that the claims as amended more distinctly define the claimed 
invention, and are patentably distinct from the references of record. The Applicant respectfully 
submits that Peachtree does not suggest or anticipate each and every limitation as now recited 
in the Applicant's claims. As such, the Applicant respectfiilly requests the Examiner to 
withdraw his rejection, and to allow all of pending claims 12-55 as amended herein. 
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The Applicant believes the above amendments and remarks to be fully responsive, 
thereby placing this application in condition for allowance. Favorable action is solicited. The 
Examiner is kindly invited to contact the undersigned attorney by telephone, facsimile, or 
email for quickest resolution, if there are any remaining issues. 



Respectfully submitted. 



Cus. No. 24222 
Maine & Asmus 
PO Box 3445 




Vernon C. Maine, Reg. No. 37,389 
Attorneys for Applicant 



Nashua, NH 03061-3445 
Tel. No. (603) 886-6100 
Fax. No. (603) 886-4796 



49 



First Named Inventor: NAULT, Jacques - TITLE: FINANCIAL STATEMENT MODULE - Atty. Dkt # 
NAU 14545-1 -^S^-^iZZ36,345 - Customer # 24222 

ANNOTED SHEET 

10/26 




i 



< 


Q 


DC 


X 




m 
o 


m 
o 


GC 





s 



s. 



On 

s- 



s 



s 



s 



5 



8 8 



■ 1 


a 




X 














e 





cN r-- OO o> 



OQ OQ Q Q Q Q 



u m o 



1 

o 
o 



• p; t/J 

8 -S 



t 
5 



O ^ CD O O ir» 

o o o o 

^ CN »o 'r> 



8 



s 



X 



2^ ep y 

04 Ah CL. 



8' 



X 



s 



o 

Hi 


a 




a 


X 














X 


e s s 




o 
u 






X 








o 

a. 


X 






Ol, 









<: PQ U Q U4 o 

o u u u a u o 




□ 



2 



□ 



< CQ O Q 

a o o a 




□ 



[ 



